On 11/10/13 14:11, Rob Stradling wrote:
> Hi Kathleen. The attached zipped .csv file implements those changes. I
> hope this is useful and saves you some effort!
Thanks, Rob!
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla
On 15/10/13 16:00, Oliver Loch wrote:
> Based on the sentences people are facing - if they start talking to
> the public - it's really possible that the hand full of people that
> know that their company handed out the root cert's private key are
> keeping their mouth shut.
It's not like the root
On 17/10/13 00:07, Phillip Hallam-Baker wrote:
> Each HSM vendor has their own security controls but a FIPS140 level 4
> device won't release them except to another FIPS-140 device. There is no
> way to extract the key from the system unencrypted.
Phil: what prevents a government just turning up w
On 28/10/13 19:27, Stephen Davidson wrote:
> Virtually every CA relying party agreement (RPA) that I know
> stipulates that a user must validate the SSL using CRL or OCSP in
> order to place any reliance on the certificate.
>
> Removal of that capability from browsers renders those RPAs useless,
>
On 19/10/13 16:35, David E. Ross wrote:
> I believe the point of contact should be someone with authority to speak
> on behalf of the CA, to make commitments for the CA, and to direct
> whatever changes the review process requires. That person should also
> be in a position that can be held accoun
On 01/11/13 23:00, fhw...@gmail.com wrote:
> Or to put it another way, everyone could stop issuing CRLs immediately
> and have no appreciable impact on Internet security. I think that would
> surprise many people.
I don't think that's true, because direct client download of the CRL is
not the on
On 12/11/13 23:20, Daniel Veditz wrote:
> This is a bandwagon we ought to hop on. See
> https://technet.microsoft.com/en-us/security/advisory/2880823
Microsoft were kind enough to make us aware of this move in advance. We
are certainly supportive.
Here's one bit of hopping:
http://blog.gerv.net/2
Prompted by Rob Stradling, I just added the following to the Potentially
Problematic Practices page:
===Backdating the notBefore date===
Certificates do not contain an issue timestamp, so it is not possible to
be certain when they were issued. The notBefore date is the start of the
certificate's
On 29/11/13 10:13, Samuel L wrote:
> I suppose that this requirement is specifically targeted at CA's that
> could try to "cheat" deadlines such as Microsoft's recent announcement
> on forbiding CA's to issue SHA-1 certs after the 1st of January, 2015 ?
1st January 2016, actually.
Yes, that kind
On 29/11/13 18:33, Brian Smith wrote:
> I suggest you propose it as a change to the baseline requirements.
Well, let's make sure we've worded it right first, and give it some time
to bake :-)
Gerv
___
dev-security-policy mailing list
dev-security-polic
On 03/12/13 11:29, Rob Stradling wrote:
> Brian, over the years we've backdated the notBefore date on several
> Intermediate certs in order to influence which of several possible
> chains gets selected by various browsers. PKI acrobatics is a good
> description. It completely sucks, but it's been
On 11/12/13 14:31, Kathleen Wilson wrote:
> There are a few cases where customers are asking CAs for more time to
> transition off of their 1024-bit certificates.
What exactly are CAs asking for? Are they asking for permission to
continue issuing such certs? Or are they asking for permission to "n
On 10/12/13 06:20, Jan Schejbal wrote:
> The third sub-ca cert (Subject AC DGTPE Signature Authentification)
> includes a CRL DP for a CRL issued by sub-ca 2, validity 2011-09-09 to
> 2014-09-13. The CRL is empty.
Look again. It seems that it now contains 1106 certificates (!), with
widely varying
On 08/01/14 06:29, Man Ho (Certizen) wrote:
> However, we know SHA-2 is a set of algorithms SHA-224, SHA-256, SHA-384,
> SHA-512, SHA-512/224, SHA-512/256. Which SHA-2 algorithm should CAs use?
Note that MS does not support SHA-224, so we can exclude that one.
Gerv
___
On 29/01/14 05:08, Brian Smith wrote:
>>> Benefits of my counter-proposal:
>>> 1. Fewer roots for us to manage.
Only for a very narrow definition of the word "root". There's the same
number of embedded trust anchor points.
>>> 3. Because of #1, there is potential for us to design a simpler root
>
On 13/03/14 19:20, Rick Andrews wrote:
> Since support for CRLs has been removed from Firefox, why does
> Mozilla's root policy
> (http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/)
> require CAs to maintain and publish CRLs?
>
> Is it because Mozilla
"You Won’t Be Needing These Any More: On Removing Unused Certificates
From Trust Stores"
http://fc14.ifca.ai/papers/fc14_submission_100.pdf
I believe there are some errors in it, like the "1500 CAs and 650
organizations" one. The biggest error is probably the suggestion that
the Mozilla trust
On 29/04/14 00:16, Kathleen Wilson wrote:
> My personal opinion…
And mine:
Free-at-the-point-of-issuance certs have been a great thing for the
Internet, and I would be very sad to see them go away. I also think in
general that the charging structures of (non-insurance :-) business
models are best
On 28/04/14 20:04, Kathleen Wilson wrote:
> Please respond with one of the following:
> A) Mozilla’s spreadsheet of included root certificates has the correct
> link to our most recent audit statement, and the audit statement date is
> correct.
> B) Here is the most recent audit statement for our c
On 26/04/14 16:45, Zack Weinberg wrote:
> If a business chooses to give some or even all of its services away
> free, those who benefit from those services are still customers and
> still in the same ethical relationship with the business as people who
> paid for services (perhaps the same service,
On 29/04/14 15:31, Jan Lühr wrote:
> I'd like to live in a world, were revocation is without any hassle an
> Community Driven CAs like CAcert are providing security for sites to be
> interested in.
That sounds to me like: "I'd like to live in a world where whatever
costs there are for having a cer
On 30/04/14 00:24, Kathleen Wilson wrote:
> On 4/29/14, 3:44 AM, Gervase Markham wrote:
>> Does the list on that wiki page need to include the Microsoft equivalent
>> of the SGC EKU? Or are we not mentioning that?
>
> Yes, it's item #1 in the "Things for CAs to F
On 30/04/14 12:39, Rob Stradling wrote:
> Bugs 982292, 982932 and 982936 talk about requiring CAs to stop
> including the Netscape Step-Up OID in _new Intermediate CA
> Certificates_, yet somehow this has morphed into "all new certificate
> issuance" on mozpkix-testing#Things_for_CAs_to_Fix.
> Was
On 01/05/14 17:55, Kathleen Wilson wrote:
>> Do we need to _stop_ people using this OID, or is it sufficient to
>> merely start to require that people use the correct one (Server Auth)?
>
> We want people to stop using the obsolete Netscape SGC OID.
Why is it not sufficient to require people to u
On 06/05/14 20:58, Brian Smith wrote:
> That isn't quite right either. It is OK for the intermediate certificate to
> omit the EKU extension entirely.
Well, not if we fix
https://bugzilla.mozilla.org/show_bug.cgi?id=968817
which Brian agreed that we could do.
RFC 5280 says (section 4.2.1.2):
On 09/05/14 01:13, Brian Smith wrote:
> We can *try* doing it for *end-entity* certificates. However:
All good points. And I think doing it for EE certs gives us the safety
we require. So let's not try for intermediates.
Gerv
___
dev-security-policy ma
On 13/05/14 01:44, Jeremy Rowley wrote:
> Also, the technical constraint of serverAuth won't work properly since
> anyEKU (or a lack of EKU) is required in some grid, EU, and fed space certs.
> Unfortunately, their policies conflict with the technical constraints
> Mozilla hopes to implement.
Hi J
On 13/05/14 03:22, Peter Bowen wrote:
> Is there a list of Extended Key Usages that are within scope for the
> Mozilla CA Program?
I hope I can get this right...
I believe the answer is: "We'd like it to be the case that only
serverAuth, and whatever the email EKU is, are in scope, and all certs
On 13/05/14 14:48, Peter Bowen wrote:
> I would add the old Netscape Step-Up/SGC (2.16.840.1.113730.4.1) and
> any EKU (2.5.29.37.0) to the list as well.
The point of the bug I reference is that we'd like to stop caring about
these (in code), because allowing anyEKU means that we include in scope
On 05/06/14 19:39, David E. Ross wrote:
> Does NSS use any code in common with OpenSSL?
Not to my knowledge, but others are far more expert than me.
> Is any part of OpenSSL
> used in any Mozilla applications?
Firefox OS ships (or used to ship) OpenSSL as part of its wifi stack.
And of course
On 21/06/14 17:15, Kurt Roeckx wrote:
> There are still a few new certificates generated with 1024 bits.
> I've been filing bugs about those and there were only a few so
> far this month.
Thank you for doing this work; it really is appreciated.
Gerv
On 24/06/14 18:17, Ryan Sleevi wrote:
> On a matter of process/procedure,
>
> When these sorts of egregious failures are noted - failures to conform to
> the required profiles or implement the specifications properly, what steps
> are taken to ensure the program operates correctly going forward?
On 23/07/14 10:06, nick.l...@lugatech.com wrote:
> The status quo today means that it is not possible to discriminate
> programatically between a DV and OV certificate in a standardized,
> reliable way.
This is because Mozilla's position is that, in security terms, there is
no relevant difference.
On 23/07/14 14:18, nick.l...@lugatech.com wrote:
> Clearly EV is very much the gold standard, but I there is a relevant
> general difference between EV and DV even if not a security one. It
> would be nice if Firefox could state that the certificate was DV or
> EV in a neutral way without making /
I am generally in favour of this plan - I think it's the right way to
go. I am not sure we will ever get to hard-fail for plain OCSP, but I am
very happy for that to be a data-driven decision somewhere down the line.
On 01/08/14 03:07, Richard Barnes wrote:
> There's one major open issue highlight
On 02/08/14 15:20, Jesper Kristensen wrote:
> * Have you considered adding support for multiple ocsp staples to allow
> stapeling of CA certs?
There is a proposed standard for multi-stapling but as far as I remember
it's not even finished yet, yet alone implemented and deployed. We
decided that we
On 04/08/14 18:44, Jesper Kristensen wrote:
> I agree that it would not be relevant for the traditional intermediate
> CA certificates in the near future for this reason. I was thinking of
> name constrained sub-CAs, which on some aspects are more similar to EE
> certs than CA certs.
OK. Let's ass
On 04/08/14 18:16, Erwann Abalea wrote:
> I imagine you have access to more detailed information (OCSP URL,
> date/time, user location, ...), could some of it be open?
Not necessarily; I suspect this data was gathered using Firefox
Telemetry, where we try very hard to avoid violating a user's priv
On 11/08/14 04:16, David E. Ross wrote:
> Rosenthal is also a reseller of X.509 subscriber certificates, which
> should mean he understands Internet security. Otherwise, how is he
> allowed to sell such certificates?
I don't often say this, because it's not often true, but...
LOL.
Gerv
__
Short-lived certs are one plank of our future revocation strategy.[0]
Currently, it is not permitted by the CAB Forum Baseline Requirements to
revocation pointers out of a cert, ever. However, this is part of the
big value of short-lived certs, as it's what unlocks their
speed-increasing potential
On 04/09/14 12:52, Hubert Kario wrote:
> It all depends on the exact definition of "short-lived". If the definition
> is basically the same as for OCSP responses or shorter, then yes, they
> provide the same security as regular certs with hard fail for OCSP
> querying/stapling.
The exact definitio
On 04/09/14 14:14, Hubert Kario wrote:
>>From what I heard (and my limited personal experience matches), is that
> the vast majority of clients not only completely ignore failures in OCSP
> retrieval (soft-fail) but completely lack any mechanism for revocation
> checking
> (be it OCSP or CRL).
I
On 04/09/14 14:18, Rob Stradling wrote:
> Today, if an end-entity cert contains no AIA->OCSP URL and the server
> sends no stapled OCSP response, it's a violation of the BRs. I wonder
> if any clients out there would reject the cert in this situation? (I
> suspect not, but it's something to watch
On 04/09/14 14:25, Rob Stradling wrote:
> When attempting to access an HTTPS site with an expired cert on Firefox
> 32, you'll see a "This Connection is Untrusted" page that lets you add
> an exception and proceed.
>
> But when attempting to access an HTTPS site with a revoked cert, you'll
> see "
On 04/09/14 18:36, David E. Ross wrote:
> Spammers change their E-mail addresses quite frequently, using the same
> address for only a day or two. Hackers also frequently change their
> "residence" so as to prevent tracing them. The same is true of
> distributors of malware.
>
> If short-lived c
On 04/09/14 19:20, Phillip Hallam-Baker wrote:
> 1) Any new scheme has to work equally well with legacy browsers and
> enabled browsers.
Yes; I think short-lived certs meet that criterion.
> 2) Ditto for legacy servers and this is actually a harder problem as
> upgrading a server can force a comp
On 05/09/14 00:06, Brian Smith wrote:
> Precisely defining a short-lived certificate is a prerequisite for a
> proper discussion of policy for short-lived certificates. It seems
> likely to me that short-lived certificates will be defined as
> certificates that would expire before the longest-accep
On 05/09/14 01:32, Phillip Hallam-Baker wrote:
> The point I am trying to get across here is that there are very few
> good reasons for an end user sticking to an obsolete browser and
> almost all would upgrade given the choice. This is not the case for
> servers and there are lots of folk who will
On 04/09/14 19:32, fhw...@gmail.com wrote:
> Could you (or anyone) elaborate a bit on the use cases where short
> lived certs are desirable?
See other messages in this thread - it saves a significant amount of
setup time not to have to wait for a response from the OCSP server.
> I'm also wonderin
On 05/09/14 10:47, Rob Stradling wrote:
> Unless the recently expired cert is found to be revoked, in which case
> you'd show "Secure Connection Failed" I presume?
Yes :-)
>> but after that we switch to "Secure Connection Failed". What do you think
>> of that idea?
>
> If the false positive rate
On 08/09/14 09:48, Kurt Roeckx wrote:
> I think those are misleading: - They count certificates that already
> expired
That is the worst error. And, they also say we've removed all the
1024-bit roots, when we haven't yet - there are still at least 3 we
haven't managed to remove yet.
Gerv
___
On 07/09/14 10:25, Jesper Kristensen wrote:
> However a stapled OCSP-response is not fully equivalent to an actively
> requested OCSP-response. A client may choose to not support stapling and
> always actively request an OCSP-response, if it believes this to be more
> secure. By allowing a short-li
On 16/09/14 23:13, Richard Barnes wrote:
> From a browser perspective, I don't care at all whether certificates
> excused from containing revocation URLs if they're sufficiently short
> lived.
>From a technical perspective, that is true. However, if we have an
interest in making short-lived cert
On 17/09/14 08:34, Kurt Roeckx wrote:
> A browser could perfectly reject a certificate that doesn't comply with
> the BR because the required OCSP URI is missing.
It could. If such browsers existed, I agree it would have a negative
effect on the likelihood of success of a short-lived certs plan. B
On 17/09/14 16:20, Richard Barnes wrote:
> There are a bunch of security features right now that I think we all
> agree improve security over and above just using HTTPS:
> -- HTTP Strict Transport Security
Check.
> -- HTTP Public Key Pinning
Others have made the point, which I agree with, that H
A question which occurred to me, and I thought I'd put before an
audience of the wise:
* What advantages, if any, do client certs have over number-sequence
widgets such as e.g. the HSBC Secure Key, used with SSL?
http://www.hsbc.co.uk/1/2/customer-support/online-banking-security/secure-key
It
On 25/09/14 13:43, Steve Roylance wrote:
> You can encrypt communications if you have a public/private key pair
You can; although most often that's provided by the server in the model
of computing most prevalent on the web today.
> You can digitally sign (with the full support of digital signatu
On 25/09/14 13:45, Michał Purzyński wrote:
> In order to leak the private cert you need to compromise the host.
> Leaking the password is easier - you can compromise the web
> application, the target server, the target company or the client’s
> machine. You have a few more attack vectors with passw
On 25/09/14 13:53, Kurt Roeckx wrote:
> On 2014-09-25 14:29, Gervase Markham wrote:
>> A question which occurred to me, and I thought I'd put before an
>> audience of the wise:
>>
>> * What advantages, if any, do client certs have over number-sequence
>>wi
On 25/09/14 17:53, Robin Alden wrote:
> I can send out a million client certificates for negligible
> cost.
Good point.
Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-securi
On 25/09/14 22:33, Matt Palmer wrote:
>> * Client certs can be invisibly stolen if a machine is compromised
>
> Well, the cert is quasi-public information, so it doesn't matter if they get
> stolen, invisibly or otherwise. The private key, on the other hand...
> But at any rate, just stick the
On 06/10/14 14:13, Phillip Hallam-Baker wrote:
> I have the configurator running for Windows Live Mail and I will add
> outlook soon. But I abandoned the attempt to do T-bird because I just
> can't get the dev system running on my Windows box despite more than a
> day trying. The documentation is i
On 20/10/14 03:10, Gregory Szorc wrote:
> Is there a good reason Mozilla can't host copies of the trusted CA
> bundle in popular formats so people can obtain a copy directly from
> Mozilla? And while we're at it, can we add some PGP signatures for
> additional verification?
One issue is, perhaps,
On 21/10/14 10:06, Anne van Kesteren wrote:
> This seemed like a good suggestion and based on what Ryan and Brian
> said I added this question to the FAQ:
>
> https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F
Anne wrote:
"The decisions Mozilla makes with regards to
https://en.greatfire.org/blog/2014/oct/china-collecting-apple-icloud-data-attack-coincides-launch-new-iphone
Cert is here:
http://www.mediafire.com/download/ampbnqncc277krv/fakeicloudcert.zip
I'd be very interested to know why (as reported) the Qihoo 360 browser
doesn't throw an error for this ce
On 27/10/14 17:58, John Nagle wrote:
> In July 2012, the CA/Browser Forum Baseline Guidelines for
> all certs, not just EV, took effect. Once those came out,
> CAs started making a clear distinction between DV, OV, and EV
> certs. Previously, DV vs OV had only been an informal distinction.
>
On 20/11/14 07:27, Peter Gutmann wrote:
> That was my immediate reaction as well. CACert has been given the runaround
> for more than just four years, it's been more than a decade, and yet as soon
> as a Mozilla-sponsored CA turns up it's in.
>
> Perhaps someone from Mozilla would be able to expl
On 28/01/15 22:49, Kathleen Wilson wrote:
> I have been asked if a CA can have their Webtrust audit statement
> indicate their commitment to comply with the BRs, rather than putting
> the commitment to comply statement in the CP/CPS.
> Here are the reason:
>
> 1) We are not a member of CAB/Forum
On 06/02/15 21:37, Kathleen Wilson wrote:
> How do you all feel about the idea of one (or more) of the
> representatives of the CAs in Mozilla's program also being a Peer of the
> CA Certificates module?
I second Jeremy's point; it seems unwise to me for someone in a formal
relationship with a CA
On 24/02/15 12:10, Juergen Christoffel wrote:
> My conclusion is that, after the 2011 incident[*] and now PrivDog,
> Comodo cannot be trusted and their Root Certificates need to be removed
> from browsers.
That's a pretty major conclusion to reach on pretty shaky evidence. Have
you actually tested
On 08/03/15 11:53, Eric Mill wrote:
> That comes down to how this program is implemented. The intent seems
> pretty clearly to identify the space CAs are already issuing in.
> Perhaps newer gTLDs merit some unrestrained time in the wild before
> they're constrained in this way
I don't understand
On 06/03/15 16:26, Richard Barnes wrote:
> https://wiki.mozilla.org/CA:NameConstraints
I am unconvinced by the wisdom of this proposal.
Others have made some of the same points, but my major objection is that
I feel that this will calcify the trust list and entrench existing
players, because inev
On 18/03/15 20:20, Daniel Micay wrote:
> The trust store policy could be changed to maintain a different level of
> accountability based on prevalence of certificates signed with the root
> certificate, but that's not the case right now. I don't think it should
> be taken into account in these deci
On 12/03/15 22:54, Peter Kurrasch wrote:
> This backwards compatibility problem is a fatal flaw, but I have an
> alternative in mind: establish and enforce boundaries within the
> intermediates. The browser can enforce a policy that a technical
> constraint be specified somewhere between the root a
On 23/03/15 15:50, Ryan Sleevi wrote:
> I think the concern would be that it still (presently) reads as
> descriptive best practice, rather than proscriptive requirement; that is
> "Mozilla's recommendation" seems far less forceful than the reality that
> it's part of the Baseline Requirements.
I
On 22/03/15 23:18, Kathleen Wilson wrote:
> I'm thinking we need to update our wiki page:
>
> https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
Well, the current list is in the BRs, so we either need to update the
BRs, or we need to decide that we want to be mo
On 23/03/15 16:41, Robin Alden wrote:
> That would be nice!
Wouldn't it? :-)
> Of all email-based domain control validation we perform those email
> addresses (on the same domain being applied for) are used as follows:
>
> admin@33.9%
> hostmaster@ 7.8%
> webmaster@
On 23/03/15 22:49, Jeremy Rowley wrote:
> Although CT would not have prevented issuance, requiring CT for all
> certificates would have detected the misissuance much sooner.
I'm not sure that's true. The intermediate itself would not count as a
misissuance. The Google cert the firewall created wo
On 24/03/15 00:00, Peter Bowen wrote:
> Is there any data on this intermediate?
>
> - Was it publicly disclosed as per Mozilla's unconstrained subordinate policy?
Kathleen would need to say to be certain, but my understanding is no.
> - Was it issued since their latest complete audit period ende
On 24/03/15 00:59, Peter Kurrasch wrote:
> Is the proposal to limit CNNIC roots to only .cn domains or would
> others be allowed?
That's a matter for discussion. We do have some data (thanks, Richard)
from CT and other places on the prevalence of CNNIC certificates in
those scans, broken down by T
On 24/03/15 02:23, David E. Ross wrote:
> What assurance is there that the mis-issued certificates were not
> intentional.
All of the evidence we have seen does fit with the scenario as outlined
in the two blog posts. Of course, most of that evidence comes from CNNIC
(and MCS via CNNIC). But the
On 24/03/15 09:03, Kurt Roeckx wrote:
> So it's my understanding that they were only supposed to issue
> certificates for their own domain(s). Why wasn't this enforced by using
> a name constraint?
The implied answer to this question from statements by the CNNIC
representative is that their syste
On 23/03/15 22:47, Richard Barnes wrote:
> We propose to add name constraints to the CNNIC root in NSS to minimize the
> impact of any future mis-issuance incidents.
I think it's worth noting that alternative options (both more and less
severe) would be considered, if people want to make a case
On 24/03/15 05:01, Peter Kurrasch wrote:
> 1) As a first step on the path to fairness, perhaps there can be
> agreement that the goal of any name constraint policy should be the idea
> that a single root does not "get the whole internet". Maybe a whole CA
> organization might, but a single root sho
On 24/03/15 09:38, Florian Weimer wrote:
> The intermediate certificate which prompted this discussion had C=EG,
> which does not align well with a limitation to the Chinese market.
I'm not entirely sure what you are saying here. Are you saying you are
suprised not to see ".eg" in that list?
> Ho
On 24/03/15 09:35, Florian Weimer wrote:
> Sadly, name constraints do not work because they do not constrain the
> Common Name field. The IETF PKIX WG explicitly rejected an erratum
> which corrected this oversight.
>
> NSS used to be different (before the mozilla::pkix rewrite), but it's
> not P
On 24/03/15 12:40, Peter Kurrasch wrote:
> I'm confused because it sounds like you're advocating for the status
> quo but I didn't think that was your position?
I am not in favour of non-consensual name constraints for CAs in
general. I think it would either be ineffective in improving security
(i
On 24/03/15 14:25, Florian Weimer wrote:
> Technically, this is true. I just find it odd that the offending
> certificate suggests a relationship with a non-Chinese market, while
> at the same time, Richard's data only shows the top gTLDs and various
> China-related TLDs.
This may be a limitation
On 24/03/15 13:18, quanxunz...@gmail.com wrote:
> As it is shown that, CNNIC doesn't have any proper audit policy for
> issuing external subCA, and it is the first time they do so, can we
> at least untrust any external subCA issued by CNNIC before their
> updating policy gets reviewed?
You mean w
On 24/03/15 21:12, Peter Kurrasch wrote:
> As to who should be forced to constrain, this is controversial. I would
> argue that everyone should be forced, but that has certain problems. One
> can argue that only government-run and certain other CA's should be
> forced but then we are put in the pos
On 25/03/15 10:27, Florian Weimer wrote:
> * The CNNIC CPS is incorrect, and they no longer run an
> Entrust-sponsored sub-CA.
I believe this is the correct answer. Quoting Bruce Morton in this thread:
"Please note that the intermediate certificate which Entrust issued to
CNNIC expired in 2012
On 25/03/15 17:45, Ryan Sleevi wrote:
> That is, in a hypothetical world where E1 is pursued (for any CA), the CA
> can simply backdate the certificate. They'd be non-compliant with the
> Baseline Requirements, presumably, but that is somewhat how we got here in
> the first place.
>
> So purely on
On 26/03/15 03:59, Peter Kurrasch wrote:
> Perhaps I chose my words poorly because my intention actually was to
> avoid having to pass judgment at all. Instead of saying to a CA "we
> don't trust you enough, please constrain" I was hoping for something
> along the lines of "everybody is asked to co
On 26/03/15 13:18, Peter Kurrasch wrote:
> So, how much work does Mozilla feel like doing?
You know my views; other Mozilla people will have to speak for
themselves. And then we'll have an argument to see whose view prevails
:-) However, this dialogue was very useful in exploring some of the
ramif
On 27/03/15 06:41, Man Ho (Certizen) wrote:
> Yeah, if this device is designed to issue certificates automatically.
> Why does it have this feature? The answer is obviously for traffic
> monitoring. But then why Paloalto would develop such problematic feature
> which violate security principle? If
On 27/03/15 19:09, Peter Kurrasch wrote:
> 1) Mozilla could refuse to validate any intermediate cert which CNNIC
> has issued to a subordinate CA. (Note: I'm not sure that's the
> technically precise term here.) Basically, CNNIC may issue
> intermediates for itself but those paths going outside the
On 30/03/15 16:34, Richard Barnes wrote:
> Adding the intermediates would allow CNNIC to continue to issue end-entity
> certificates, and not penalize site owners immediately (as Peter notes).
> However, it would prevent the acceptance of other intermediates, since the
> improper issuance of interm
On 31/03/15 02:34, Peter Gutmann wrote:
> So this is now a convenient excuse to kick out CNNIC, after the initial
> attempts to not let them in in the first place failed. I've always wondered,
> what do people have against CNNIC and Turktrust in particular?
I haven't seen anyone in this thread m
On 30/03/15 16:34, Richard Barnes wrote:
> After some further thought on this issue, I would like to propose the
> following course of action:
>
> 1. Remove the CNNIC root certificates
> 2. (possibly) Temporarily add the CNNIC intermediate certificates
After consideration, I want to record two po
On 01/04/15 22:41, Richard Barnes wrote:
> That's certainly an option. I didn't want to prescribe a specific
> mechanism in my initial proposal, since this seemed like an implementation
> detail. In principle, just a list of issuer/serial pairs would be
> sufficient to recognize bad certs, if CNN
1 - 100 of 1053 matches
Mail list logo
